Skip to content

Add #_objectFileFormat compilation conditional #80212

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add #_objectFileFormat compilation conditional #80212

wants to merge 2 commits into from

Conversation

kubamracek
Copy link
Contributor

This implements the relevant part of the "Section Placement" proposal (draft: https://github.com/kubamracek/swift-evolution/blob/section-placement-control/proposals/0nnn-section-control.md, forum thread: https://forums.swift.org/t/pitch-3-section-placement-control/77435). Namely the ability to conditionalize on the object file format that the compiler is targeting (MachO, ELF, COFF of Wasm).

Adding with an underscored name (#_objectFileFormat) until the proposal is codified.

rdar://147505228

@kubamracek
Copy link
Contributor Author

@swift-ci please test

compnerd
compnerd reviewed Mar 21, 2025
View reviewed changes
lib/Basic/LangOptions.cpp Outdated
Comment on lines 654 to 677
// Set the "_objectFileFormat" platform condition.
if (Target.isOSBinFormatMachO()) {
addPlatformConditionValue(PlatformConditionKind::ObjectFileFormat, "MachO");
} else if (Target.isOSBinFormatELF()) {
addPlatformConditionValue(PlatformConditionKind::ObjectFileFormat, "ELF");
} else if (Target.isOSBinFormatCOFF()) {
addPlatformConditionValue(PlatformConditionKind::ObjectFileFormat, "COFF");
} else if (Target.isOSBinFormatWasm()) {
addPlatformConditionValue(PlatformConditionKind::ObjectFileFormat, "Wasm");
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we rewrite this as:

addPlatformConditionValue(PlatformConditionKind::ObjectFileFormat,
  llvm::StringSwitch<llvm::Triple::ObjectFormatType>(Target.getObjectFormat())
    .Case(llvm::Triple::COFF, "COFF")
    .Case(llvm::Triple::ELF, "ELF")
    .Case(llvm::Triple::MachO, "MachO")
    .Case(llvm::Triple::Wasm, "Wasm"));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, not really, because we're not switching over strings here, but over the enum cases... I could do a regular switch, but that reads worse than the chain of ifs:

  StringRef FileFormatName;
  switch (Target.getObjectFormat()) {
  case llvm::Triple::COFF:
    FileFormatName = "COFF";
    break;
  case llvm::Triple::ELF:
    FileFormatName = "ELF";
    break;
  case llvm::Triple::MachO:
    FileFormatName = "MachO";
    break;
  case llvm::Triple::Wasm:
    FileFormatName = "Wasm";
    break;
  default:
    break;
  }
  if (!FileFormatName.empty()) {
    addPlatformConditionValue(PlatformConditionKind::ObjectFileFormat,
                              FileFormatName);
  }

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The covered switch would make it easier to identify new cases though I think. It is more that I am after a switch rather than a series of cascading if conditions.

@kateinoigakukun
Copy link
Member

Should we consider gating this behind an experimental feature flag?

@kubamracek
Copy link
Contributor Author

I'm happy to do that if we deem that necessary, though all the other existing not-yet-ratified compilation conditions (e.g. pointerBitWidth) don't do that and just use an underscore.

@kubamracek kubamracek mentioned this pull request Mar 22, 2025
Merged
@kubamracek
Copy link
Contributor Author

swiftlang/swift-syntax#3027

@swift-ci please test

@grynspan
Copy link
Contributor

Should we consider gating this behind an experimental feature flag?

Swift Testing will need to make use of this to support Embedded Swift, and requiring an experimental flag will make it more difficult to do so. (When it gets formally featurized, we can eagerly adopt the final version.)

grynspan
grynspan reviewed Mar 23, 2025
View reviewed changes
lib/Basic/LangOptions.cpp
addPlatformConditionValue(PlatformConditionKind::ObjectFileFormat, "COFF");
} else if (Target.isOSBinFormatWasm()) {
addPlatformConditionValue(PlatformConditionKind::ObjectFileFormat, "Wasm");
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add an else clause here that diagnoses the target is unknown? That way if we add a new port, we'll know to update this code.

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

swiftlang/swift-syntax#3027

@swift-ci please test

@kubamracek
Copy link
Contributor Author

swiftlang/swift-syntax#3027

@swift-ci please test

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@grynspan
Copy link
Contributor

grynspan commented Mar 30, 2025 •
edited
Loading

Are there any other object formats that LLVM supports? Should we add cases for them even if Swift itself hasn't added toolchain support?

Edit: The following are all the cases in the object format enum in the Swift repo:

  enum ObjectFormatType {
    UnknownObjectFormat,

    COFF,
    DXContainer,
    ELF,
    GOFF,
    MachO,
    SPIRV,
    Wasm,
    XCOFF,
  };

So it may make sense to just switch over the whole enum (with getObjectFormat()).

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

Are there any other object formats that LLVM supports? Should we add cases for them even if Swift itself hasn't added toolchain support?

Edit: The following are all the cases in the object format enum in the Swift repo:

  enum ObjectFormatType {
    UnknownObjectFormat,

    COFF,
    DXContainer,
    ELF,
    GOFF,
    MachO,
    SPIRV,
    Wasm,
    XCOFF,
  };

So it may make sense to just switch over the whole enum (with getObjectFormat()).

I think it's probably undesirable to go beyond the 4 object file formats that Swift targets today, because (1) we'd have to lock down the specific spelling of those and (2) it would suggest that the compiler is actually capable of producing valid object files in these formats, but that's almost certainly not true until someone actively builds that support.

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

@swift-ci please test macOS platform

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@compnerd
Copy link
Member

compnerd commented Apr 8, 2025

it would suggest that the compiler is actually capable of producing valid object files in these formats, but that's almost certainly not true until someone actively builds that support.

I don't know if I agree here. However, we do in a number of places currently just abort if you use a different object file format. Some of these are unlikely to ever be supported (e.g. DXContainer and SPIRV), so adding the full coverage really doesn't add much value, but does add noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@compnerd compnerd compnerd left review comments

@grynspan grynspan grynspan left review comments

@kateinoigakukun kateinoigakukun kateinoigakukun approved these changes

@jckarter jckarter Awaiting requested review from jckarter

@phausler phausler Awaiting requested review from phausler

@mikeash mikeash Awaiting requested review from mikeash

@DougGregor DougGregor Awaiting requested review from DougGregor DougGregor is a code owner

@ahoppen ahoppen Awaiting requested review from ahoppen ahoppen is a code owner

@zoecarver zoecarver Awaiting requested review from zoecarver

@eeckstein eeckstein Awaiting requested review from eeckstein

@bnbarham bnbarham Awaiting requested review from bnbarham bnbarham is a code owner

@CodaFi CodaFi Awaiting requested review from CodaFi CodaFi is a code owner

@hamishknight hamishknight Awaiting requested review from hamishknight hamishknight is a code owner

@rintaro rintaro Awaiting requested review from rintaro rintaro is a code owner

@hborla hborla Awaiting requested review from hborla hborla is a code owner

@slavapestov slavapestov Awaiting requested review from slavapestov slavapestov is a code owner

@xedin xedin Awaiting requested review from xedin xedin is a code owner

@MaxDesiatov MaxDesiatov Awaiting requested review from MaxDesiatov

@artemcm artemcm Awaiting requested review from artemcm artemcm is a code owner

@tshortli tshortli Awaiting requested review from tshortli tshortli is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@kubamracek @kateinoigakukun @grynspan @compnerd